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ABSTRACT 

mhis  is  a  working  paper  for  IFIP  Working  Group  2.?  (Numerical  Softwar 
to  stimulate  discussion  of  a  possible  group  project.  The  project  is  to 
describe  the  facilities  in  a  programming  language  that  make  it  useful  for 
numerical  computation.  The  facilities  are  classified  and  their  importance 
measured.  This  paper  presents  a  framework  for  this  project  and  is  an  ini* 
draft  of  the  facility  descriptions.  The  opinions  and  ratings  contained  be 
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SIGNIFICANCE  AND  EXPLANATION 


Many  proaramming  languages  being  introduced  are  used  primarily  in 
numerical  applications ,  but  there  is  no  source  to  amide  the  lanauage  designer 
ir.  selecting  the  facilities  (capabilities)  to  be  included.  This  working  paper 
provides  a  framework  for  such  a  source  and  presents  an  initial  draft  of 
material  for  ten  topics.  Facilities  are  described  in  qeneral  terms;  as  "what 
it  should  be  possible  to"  rather  than  "this  is  how  it  should  be  included"  .  I*- 

is  recognized  that  there  are  many  ways  to  provide  a  facility  within  the  design 
of  a  programming  language.  This  working  paper  is  part  of  the  activities  of 
IFIP  Working  Group  2.5  (Numerical  Software). 


The  responsibility  for  the  wording  and  views  expressed  in  this  descriptive 
summary  lies  with  MRC,  and  not  with  the  author  of  this  report. 
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PROGRAMMING  LANGUAGE  FACILITIES  FOR  NUMERICAL  COMPUTATION 

John  R.  Rice 

INTRODUCTION 

New  proqrammina  languages  are  still  appearing  and  old  ones  are  being 
modernized.  Even  though  the  bulk  of  the  use  of  these  languages  is  numerical, 
there  is  no  source  to  guide  the  language  designer  in  the  selection  of 
facilities  to  he  included  in  a  languaae.  The  aim  here  is  to  produce  such  a 
source.  Facilities  are  described  in  functional  terms  and  there  is  no 
intention  to  describe  syntax  or  even  the  details  of  semantics.  There  is  no 
discussion  of  "general  purpose"  language  facilities  unless  there  is  some 
special  aspect  of  this  facility  relevant  to  numerical  computation.  It  is 
recoanized  that  there  are  normally  many  ways  to  provide  a  given  capability 
within  a  particular  programming  language  design.  This  working  paper  has  been 
motivated  and  stimulated  by  the  report  of  Dekker  [1979]  where  some  of  the 
ideas  expressed  here  are  already  found. 

A  framework  is  presented  here  for  WG2.5  to  consider  for  developing  a 
source  useful  to  language  designers.  It  is  proposed  to  have  a  list  of  perhaps 
20  topics  and  to  discuss  each  in  the  following  format:  (a)  brief  general 
definition,  significance  and  background  for  the  topic.  (b)  Brief  descriptions 
of  specific  facilities  that  have  been  or  would  be  useful  for  numerical 
computation.  (c)  Examples  of  how  such  facilities  have  been  or  would  be 
included.  The  facilities  are  rated  according  to  their  estimated  ease  of 
inclusion  in  a  language?  facilities  already  widely  available  are  rated  near 
100;  those  that  are  premature  within  the  present  programming  technology  and/or 
computer  resource  constraints  are  rated  near  0.  The  facilities  are  also  rated 
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by  importance;  a  ratiiig  near  100  means  a  language  lackino  this  fac 
unlikely  to  be  used  for  significant  numerical  computation. 
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2.  CLASSIFICATION  OF  FACILITIES 


The  numerical  values  to  be  assigned  to  properties  of  the  facilities 
discussed  will  have  considerable  subjectivity.  Furthermore,  some  facilities 
are  speculative  in  nature  and  there  could  well  be  unforeseen  difficulties  or 
benefits  from  their  inclusion  in  a  language.  Nevertheless,  judgements  shoul  i 
still  be  made.  A  guide  is  given  to  assigning  numerical  values  for  ease  of 
inclusion  and  importance. 

For  ease  of  inclusion  we  consider  two  aspects:  the  actual  effort  to 
include  a  facility  and  the  frequency  with  which  it  is  currently  included.  A 
facility  that  requires  considerable  effort  to  include  and  yet  which  is  widelv 
included  would  receive  a  high  rating  for  ease  of  inclusion  on  the  basis  that  a 
language  designer  is  likely  to  put  it  in  anyway. 

Ease  of  Inclusion 

Rating _ Description  of  Facility  Inclusion _ 

80-100  Widely  available  or  something  that  should  be  relatively  straight¬ 
forward  to  do  without  a  significant  perturbation  of  the  language 
design  or  implementation  (e.g.  a  new  intrinsic  function) . 

50-85  Something  currently  missing  from  some  important  languages,  but  which 
can  be  added  with  moderate  effort  and  without  a  major  change  in  the 
language  (e.g.  inclusion  of  expressions  in  output  statements  or  loon 
control,  inclusion  of  bit  data  type). 

30-60  Something  which  requires  a  major  change  to  add  to  a  language; 

something  which  may  substantially  increase  the  complexity  of  the 
translator  (e.g.  completely  dynamic  storage  allocation  with  garbage 
collection,  symbolic  differentiation  in  a  Fortran  or  Algol-60  like 
language) . 
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-  '  r-thino  vv'-ich  chances  the  character  of  the  ianguacie  ;  c 

reauire  resources  in  translation  or  execution  that  are  present ]v  ■-  • 
tenerallv  available  (e.g.  inclusion  of  a  ranae  of  qeneral  problem 
solvino  statements,  symbolic  and  numerical  manipulation  of  function 
and  array's  of  functions). 

for  importance  we  simnly  judge  the  overall  usefulness  of  a  facility. 

■  in  mind  that  criven  any  facility  there  are  some  proarams  that  do  not  use 
if  and  others  which  are  helped  crreatly  by  it.  The  aspects  of  computinq 
considered  in  the  evaluations  are:  (a)  clarity  and  effort  of  programming 

b )  use  of  machine  resources,  (c)  methodology  for  large  scale  projects 
'portability,  modularity,  etc.), 
importance 

rating _ Description _ 

"0-inn  Lack  of  this  facility  greatly  complicates  a  wide  variety  of  programs 
and  probably  eliminates  the  languaae  from  consideration  in  numerical 
computations . 

fr,-8P  a  smaller  percentacre  of  the  numerical  software  will  be  affected  but 
the  facility  is  still  important  enough  to  merit  a  redesign  of  the 
language  in  order  to  have  it  included. 

30-50  A  facility  with  relatively  infreauent  use  (only  3-8%  of  the  programs) 
or  for  which  there  is  a  straightforward  (but  perhaps  obscure, 
cumbersome  or  inefficient)  means  to  accomplish  the  same  result. 

1 Example;  partitioning  workspace  through  a  dummy  intermediate 
subprogram.)  Such  facilities  shojuld  be  included,  but  might  be 
sacrificed  to  other  considerations  of  the  language  desion. 

'~2r<  Nice,  convenient  at  times,  but  not  essential. 
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A  sucigested  list  of  topics  is  given.  There  is  considerable  overlap  at 
sone  points  and  discussions  of  one  topic  may  refer  to  those  of  others.  In  ar.  v 
case,  this  overlap  is  alright  as  Iona  as  no  contradictions  are  created.  The 
given  order  is  random. 

1.  Library  Facilities 

2.  Array  Definitions  and  Manipulation 

3.  Vector-Matrix  Algebra  and  Operations 

4.  Input/Output  Facilities 

5.  Calculus  Operators 

6.  Mathematical  Functions  Definition  and  Manipulation 

7.  Inter-program  Communication 

9.  Standard  Mathematical  Functions 
9.  Exception  and  Error  Handling 
in.  Variable  Types 

11.  Environment  Information 

12.  Precision  Control 

13.  Declarations  and  Names 

14.  Problem  Solving  Statements 

15.  Storage  Management 

16.  Data  Structures 
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INITIAL  DRAFT  OF  FACILITY  DESCRIPTIONS 


TOPIC  1:  Library  Facilities 

A.  General  Discussion 

Numerical  computation  is  normally  supported  by  an  extensive  lihrarv  '  f 
programs.  The  contents  vary  from  general  purpose  (e.q.  sin(x),  solve  a  i - •••  . 
system  of  equations)  to  very  specialized  (e.g.  calculate  the  thermal 
conductivity  of  laminate  of  several  materials).  A  typical  user  has  access  * 
500-1000  library  programs. 

B.  Facilities 

1.  Access  to  machine  parameters.  Many  standard  programs  depend  on  parameters 
such  as  machine  word  length,  characters  per  word  or  machine  precisi  on . 
comprehensive  set  of  these  should  be  available  within  the  comouting 
environment. 

Rating;  Ease  =  95,  Importance  =  F1" 
The  paper  of  Ford  [1978]  gives  a  standard  set  of  machine  parameters . 

These  can  be  made  available  either  as  reserved  names  of  the  languaae  or  bv 
calling  an  intrinsic  library  function.  Some  of  these  parameters  are  available 
as  by-products  of  functions  to  manipulate  integer  and  floating  point 
variables,  see  Reid  [1978],  Brown  [1979] .  Mechanisms  to  provide  this 
information  are  used  rather  widely  by  those  preparino  software  targeted  to 
many  machines,  see  Aird  [1977]  for  an  example. 

2.  Separate  Compilation.  The  concept  of  a  library  itself  depends  on  the 
ability  to  independently  develop  subprograms  for  other,  unknown  proarans 
to  use. 

Rating;  Ease  =  80,  Importance  =  Q9 
Separate  compilation  is  available  in  a  number  of  languages,  but  missino 
in  some  important  ones.  Those  languages  where  it  is  missing  are  either 
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desiqned  for  small  scale  computing  or  allow  "extra-lingual"  access  to 
independently  compiled  programs,  including  programs  from  other  languages. 

'"his  latter  alternative  is  better  than  nothing,  but  clearly  ir.adenuate  as 
is  compiler  and/or  system  dependent. 

3.  Dynamic  Workspace  Allocation.  It  is  common  for  an  algorithm  to  need, 
temporary  variables  whose  number  is  not  known  until  execution.  It  shoul  i 
be  possible  to  obtain  memory  space  for  these  variables. 

Rating:  Ease  =  50,  Importance  -  60 

The  objective  is  to  create  an  array  ARRAY ( I ) ,  I  =  1  to  N  within  a 
subprogram  when  N  is  specified  at  execution  time.  Many  languages  allow 
this,  but  if  it  is  missing  then  a  workspace  array  must  be  passed  to  the 
subprogram.  The  majority  of  programmers  do  not  understand  how  parameters  are 
passed  between  programs;  they  are  particularly  ignorant  about  array  parameters 
and  thus  passing  workspace  is  particularly  error  prone.  Those  languages  whose 
typing  of  arrays  is  so  strong  that  it  prevents  passing  them  to  separately 
compiled  subprograms  are,  of  course,  particularly  inadequate  for  libraries. 

4.  Hiding  Names.  Library  programs  are  sometimes  themselves  large  programs 
with  many  subprograms.  The  choice  of  names  for  or  within  these  programs 
should  not  affect  a  user's  program. 

Rating:  Ease  =  70,  Importance  -  30 

Block  structures  may  be  used. to  localize  the  existence  of  names  and  is 
quite  common.  Group  structures,  as  presently  proposed  for  inclusion  in  the 
next  Fortran,  are  equally  effective  and  are  less  constraining  on  the  other 
facilities  within  a  language. 


1 
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T'v;.'  Arr-iv  'V-f  i  r.  I  t  ions  and  Facilities 

A.  "-en^nl  Pis--ussion 

“•rravs  are  the  most  fundamental  ->ata  structure  of  numerical 
•'orrutatior..  They  permeate  the  mathematical  and  physical  theories  as  well  a.- 
arise  naturally  in  a  wide  variety  of  al  crorithms .  It  is  therefore  important 
t’-a"  special  attention  he  paid  to  provide  versatile  facilities  for  their  use. 

~ .  facilities 

1.  Complete  Internal  Specif ication .  The  internal  representation  of  ar 
irrv  '"s-uld  contain  complete  information  about  its  nature  as  well  as  its 
value.  Thus  al 1  declared  information  (e.o.  Type  =  Real,  3-Dimensions, 
Symmetric  Storage,  Dimension  Ranges  =  (11,10,5),  Range  Indexes  =  ( IA, JA , KA ) 1 
should  be  a  part  of  the  representation  or  directly  available  from  the  context 
without  any  special  effort  on  the  part  of  the  programmer.  Any  passing  of  tr>- 
arrav  between  programs  would  automatically  carry  alona  this  information. 

Rating :  Ease  =  70,  Importance  =  7- 

This  facility  is  aimed  at  making  true  data  types  of  arrays.  At  executin' 
time  one  knows  all  the  information  about  numeric  variables  and  this  treatmenr 
should  extend  to  arrays.  Flock  structure  languages  can  accomplish  this  by 
never  allowing  the  use  of  a  variable  to  be  "hidden"  from  its  declarations. 

2.  Array  Puilding  and  Subarray  Extraction.  It  is  common  to  build  arrays 
from  pieces  and  to  analyze  or  use  them  in  parts.  The  most  common  situations 
are  to  build  r-d imensional  arrays  from  (?)  -  1  )-dimensional  ones,  to  "border" 

.-j  oi'/en  array  to  enlarge  it,  to  extract  (N  -  1 ) -dimensional  arrays  from 
"-dimensional  ones  and  to  extract  similar  but  smaller  arrays  from  a  given 
one.  Facilities  are  needed  to  do  this  naturally  and  directly.  These 


*  .V'  i )  i  t'roVar!  v  de;x»p.d  on  the  presence  of  the  array  operations  ner.t  iop.c 

below. 

Patina:  Ease  =  55,  Importance  =  ?r 

These  facilities  have  been  included  in  several  lanauaaes  and  consi^erah! 
experience  qained  with  their  use,  see  NAP5S  [1956],  Payer  [19711,'  Paul 
[1979;.  Such  a  set  of  facilities  has  been  proposed  for  the  next  revision  of 
Fortran . 

3.  Array  Operations.  The  basic  arithmetic  operations  should  he  extende 
to  arrays  on  an  element  by  element  basis.  Thus  C=A+R  or  A  =  A  -  B  is 
allowed  provided  the  arrays  conform.  Similarly  functions  are  extended  to 
arrays  as  loa(A)  =  array(  log  (a^))  if  A  =  a^.  Finally,  constants  should 
be  "broadcast"  within  array  expression  so  that,  for  example,  3  can  be  used  fo 
the  array  with  all  elements  =  3. 

Rating:  Ease  =  65,  Importance  =  55 

4.  Range  Indices.  A  range  index  of  an  array  is  a  variable  whose  value 
is  the  current  size  of  the  array.  Thus  one  might  declare  (in  a  clumsy  form 
for  clarity) 

Real  Array  A/Dimension  =  1/Storage  =  100/Range  Index  =  NA/ 

Thus  changing  NA  changes  the  working  size  of  A  as  it  would  be  used  in  a 
calculation.  If  the  language  has  full  dynamic  storage  allocation,  then  the 
storage  information  is  not  needed;  it  is  particularly  useful  to  explicitly 
distinguish  between  storage  information  and  the  working  size  of  an  array. 

Rating:  Ease  =  60,  Importance  =  65 

The  VECTRAN  language  contains  range  indices  in  an  environment  without 
dynamic  storage  allocation.  A  similar  proposal  has  been  made  for  the  next 
fortran  revision.  People  experienced  in  consulting  with  users  of  libraries 
report  that  a  significant  percentaoe  (30-50)  of  all  the  "non-trivial" 


basis.  Then  A  *  B  and  A  t  2  do  not  mean  "A  times  B"  and  "A  . 

identity  matrix  could  be  represented  by  a  generic  (with  respect  *-■-  size  a? 
well  as  type)  reserved  word,  a  function  such  as  IDENT(N)  or  I DENT ( A )  Cher-1 
A  determines  type  and  size)  or  A^ .  The  transpose  can  also  be  represer. t?i 
a  function  or  special  operator.  It  is  a  delicate  problem  to  choose  natura! 
syntax  in  a  language  that  has  both  array  operations  and  vector-matrix  alaeb;  i 

2.  Matrix-Vector  Algebra.  A  vector  is  considered  to  be  an  N  *  1 
matrix  (column  vector)  and  all  matrix  operations  on  vectors  are  interpret?: 
this  way. 

Rating :  Ease  =  60,  Importance  =  7C, 

It  is  natural  to  include  vectors  in  the  matrix  algebra  scheme  and  then 

one  must  resolve  the  ambiguity  of  "x  times  y" ;  it  is  Z  x.y.  (dot  product)  n 

the  array  A  =  {x.y.  =  a..}? 

l  3  13 

3.  Submatrix  Selection.  A  mechanism  to  select  submatrices  (includinn 
row  and  column  vectors). 

Rating ;  Ease  =  55,  Importance  =  40 

See  the  remarks  in  Example  2,  item  2. 

4.  Inverse  Matrices  and  the  Solution  of  Linear  Equations.  The  matrix 
inverse  A-^  is  to  be  included  and  one  can  express  the  solution  of  the 
equations  Ax  =  b  as  x  =  A-^b.  A  separate  linear  equation  solution  facilit 
might  be  provided  for  additional  flexibility. 

Rating:  Ease  =  50,  importance  =  60 

The  matrix  inverse  and  solution  of  equations  is  a  facility  at  a  hiqher 
level  than  commonly  included  in  current  "high"  level  languages.  The  code  to 
implement  it  is  longer  (50  plus  statements  in  Fortran)  and  there  is  no  truly 
reliable  test  for  the  failure  of  the  operation  (when  the  matrix  is 


singular)  .  '•  si  r.-tul  ir  "atrix  failure  is  of  a  i ■_  •  v're"-  -  •  :r  t'-n-. 

exception;:  an’  must  be  indicated  appronr iately . 

S.  Matrix-Vector  Constants.  See  Facility  ^  of  Example  2. 

Rating :  Ease  =  7S,  Importance  =  if 

See  the  remark  for  Example  2,  item  R. 

o.  Specialized  Matrix  Structures.  In  addition  to  the  general  full 
'■price:,  there  is  a  variety  of  well  identified  and  common  structures:  hand, 
symmetric,  symmetric  hand.  Special  representations  of  these  matrices  are 
essential  in  many  applications  in  order  to  efficiently  use  computer  time  an. 
memory.  Such  representations  can  be  included  in  the  language  if  appropriate 
declarations  and  operator  varieties  are  included. 

Rating;  Ease  =  40,  Importance  =  4° 

The  specialized  matrix  structures  are  important  enough  to  have  relevanr 
facilities  included  in  major  libraries.  Thus  a  translation  writer  will  have 
little  difficulty  in  implementing  the  matrix  operations,  but  the  complexity  <- 
declared  types  increases  somewhat  (e.g.  REAJ,  POSITIVE  DEFINITE  BAND  MATPIV 
A(in,l0)).  There  is  also  the  added  complexity  of  checking  compatibility  in 
matrix/vector  operations. 

TOPIC  4;  Input/Output 

A.  Ceneral  Discussion 

Numerical  computation  naturally  involves  vectors,  matrices  and  functions 
thus  a  language  should  facilitate  input  and  output  involving  them. 

B.  Facilities 

1.  Tabular  Output.  One  wants  to  say  "TABLE  X,  DA(TA  1 ,  DATA  2"  or  "TABI,: 
MATRIX"  and  automatically  receive  a  reasonable  table  on  the  standard  output 
device  (printer).  The  dimensions  of  the  table  are  determined  by  the  working 
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3:  ,vs  ,  -f  -h«»  vectors  or  matrices  involved;  headings  are  oiven  alon-i  w:  t  1  sr. 
i  ?ex  ;  ”'i . 

Rating:  Fa.se  =  a0 ,  Imnor'an'- 

The  sa~e  facility  for  functions  is  needed.  There  is  a  slierht  complication  in 
choosing  the  ranoe  and  increment;  defaults  and/or  specifications  (e.u.  "TAP! 
FTrypT  o;o  [0,6"'  ",  should  he  implemented. 

Rating :  Ease  =  °F  ,  Importance  ~  FF 

This  facility  is  primarily  to  reduce  to  detailed  and  error-prone 
specifications  commonlv  reouired  to  produce  even  a  simple  table.  The 
implementation  of  tabulation  is  not  very  difficult  if  fairly  inflexible 
formats  are  used.  The  tabulation  of  functions  requires  more  information  (the 
ranqe  and,  for  multivariate  functions,  the  independent  variable  plus, 
nossibly,  values  for  other  variables)  and  hence  more  complex  syntax.  Sue)' 
facilities  have  been  included  in  a  variety  of  svstems. 

2.  Printer  Plotting.  The  printer  plotting  facility  is  similar  to  the 
tabulation  facility  above;  a  similar  syntax  could  be  used  to  produce  "working 
quality"  plots  of  groups  of  vector  (e.g.  PI.OT  K  VERSUS  DATA  1,  DATA  2)  or 
functions . 

Rating ;  Ease  =  80,  Importance  =  70 

Printer  plotting  is  currently  a  common  library  routine  which  should  be 
part  of  a  numerical  computation  language.  Even  crude  printer  plots  require 
considerable  thought  (and  code)  to  implement  well,  see  [xxxx]  for  example 
algorithms . 

3.  Graphical  System  I/O.  In  addition  to  the  common  printer  plotting 
capability,  one  wants  access  to  a  system  which  gives  much  higher  resolutions 
and  more  capabilities.  A  detailed  description  of  such  capabilities  is  not 
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,'iven;  hopefully  they  will  be  rather  common  and  somewhat  standardized  in  the 


near  future. 

Rating ;  Ease  =  50,  Importance  =  "" 

A  connection  to  a  graphical  system  essentially  requires  the  very 
widespread  availability  of  facilities  accessed  from  the  language.  The  trend 
in  graphical  systems  is  in  this  direction  (see  [Synder,  1«78] ,  [SIGGRAPH 
Notices]  for  an  example  and  for  further  discussion) .  The  range  of 
capabilities  possible  within  a  graphics  system  is  very  broad  and  one  of  the 
critical  design  points  is  to  identify  a  useful  subset  that  can  be  accessed 
naturally  and  concisely.  Universality  of  the  language  can  be  achieved  by 
having  the  graphical  access  default  to  printer  plotting  when  no  graphical 
system  is  available. 

4.  Data  Storage  Access.  Data  in  the  form  of  vectors,  matrices  or  just 
groups  of  variable  values  should  be  available  from  the  computer  system  data 
storage  facility.  This  capability  is  useful  both  for  input  and  output. 

Rating:  Ease  =  40,  Importance  =  35 

The  basic  aim  is  to  allow  one  to  create  or  enter  data  into  a  computer 
system,  manipulate  it  and  pass  it  from  program  to  program  with  minimal 
attention  (on  the  programmer's  part)  to  storage  formats  and  related  matters. 
The  basic  facility  needed  here  is-  much  less  than  a  general  data  base  system  in 
that  simple  data  structures  are  involved  (aggregates  of  variables,  vectors  or 
matrices)  which  are  handled  as  integral  units.  Such  facilities  are  commonly 
available  in  file  handling  systems.  As  with  access  to  a  graphics  system,  the 
crux  of  the  design  here  is  to  identify  a  useful  subset  that  can  be  accessed 
naturally  and  concisely. 
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TOPIC  5:  Calculus  Operators 


A.  General  Discussion 

The  training  of  scientists  and  engineers  includes  an  almost  universal 
introduction  to  a  number  of  basic  operators  which  we  loosely  call  the  calculus 
operators.  Some  of  these  (sum  =  I,  product  =  IT,  max,  min)  are  simple  finite 
operators  which  can  be  incorporated  easily  into  a  language.  others  - 
differentiation,  integration,  infinite  summations  and  function  extrema  -  are 
algorithmically  much  more  complex. 

The  operators  of  facilities  2  through  5  cannot  he  implemented  by  an 
algorithm,  their  values  are  not  computable  functions  (technically  speakina)  of 
their  arguments.  Their  inclusion  in  a  language  thus  represents  a  significant 
new  feature.  Implicit  in  the  ease  ratings  is  the  belief  that  the  state  of  the 
art  allows  one  to  implement  them  reliably.  That  is,  in  practice  oood 
estimates  can  be  obtained  in  most  cases;  computational  failure  can  be  detects.: 
in  most  of  the  remaining  cases  and  truly  erroneous  results  are  produced  in  a 
very  small  fraction  of  the  computations.  The  level  of  reliability  of  these 
implementations  will  be  comparable  to  that  of  general  numerical  computation 
and  probably  better  them  currently  exists  in  most  programs  where  such 
operators  are  supposedly  used. 

Another  new  aspect  of  these  operators  is  the  complexity  of  the  algorithm? 
used  to  implement  them;  they  will,  run  to  hundreds  (and  possibly  thousands)  of 
statements  in  a  language  at  the  Fortran-Algol  level. 

B.  Facilities 

1.  The  Finite  Operators.  The  three  most  important  are  MAX,  MIN  and  Z 
which  operate  on  vectors  or  matrices.  A  range  or  domain  must  be  used;  vectors 
and  matrices  are  likely  to  have  a  range  variable  which  can  be  used  as 
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default.  The  product  operator  II  is  much  less  comnor.lv  is--’,  s  *  it  -iobt  be 
included  for  the  sake  of  completeness.  Extensions  to  other  operators  of  a 
similar  nature  (e.g.  average,  median)  could  also  he  incuded. 

Rating :  Fase  =  90,  Importance  =  RO 

The  finite  operators  are  straightforward  to  include  in  a  language  and 
their  widespread  occurrence  makes  it  unreasonable  to  exclude  them. 

2.  Differentiation.  The  derivative  of  a  function  of  one  variable  may  be 
evaluated  symbolically  or  estimated  numerically.  The  difference  between  these 
two  choices  is  very  large;  both  in  the  nature  of  the  results  obtained  and  the 
technique  of  implementation.  The  partial  derivative  of  a  multivariate 
function  can  be  obtained  by  indicating  which  variable  is  to  be  considered  as 
the  independent  variable. 

Rating  (symbolic);  Ease  =  40,  Importance  =  75 
Rating  (numerical):  Ease  =  60,  importance  =  50 
Differentiation  is  unique  in  that  a  numerical  implementation  is  tricky 
while  a  symbolic  implementation  is  not  conceptually  difficult.  Technically 
speaking,  differentiation  is  an  unbounded  operator  and  this  manifests  itself 
in  practice  by  making  the  estimation  difficult.  On  the  other  hand,  it  is 
feasible  to  symbolically  differentiate  more  or  less  arbitrary  programs  ( see 
rCrary,  1979],  [Kedem,  1979]).  Symbolic  differentiation  does  require 
substantial  manipulation  of  the  source  text.  This  can  be  done  at  translation 
time,  but  this  approach  is  not  very  compatible  with  separate  compilation. 

Poth  numerical  and  symbolic  differentiation  were  implemented  in  the  NAPSS 
system  [Poman,  196P] ,  [Symes,  1967],  [Oldehoeft,  1972]  and  it  was  found  that 
the  symbolic  implementation  was  significantly  more  efficient  and  significantly 
more  reliable. 
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3.  Integration.  The  integral  of  a  function  of  one  variable  ma’’  he 
estimated  numerically  or,  in  some  cases,  evaluated  symbolically .  The 
difference  between  these  two  choices  is  as  large  as  for  differentiation,  but 
the  balance  is  considerably  different.  A  syntax  close  to  the  mathematical  one 

b 

'  f  (  x )  dx 
a 

should  be  adopted.  The  function  f(x)  may  depend  on  variables  in  addition 
to  x . 

Rating  (symbolic):  Rase  =  30,  Importance  -  40 
Rating  (numerical):  Ease  =  70,  Importance  =  50 
Integration  is  the  classical  example  of  a  non-computable  operator;  one 
can  easily  construct  a  function  for  any  given  algorithm  which  leads  to  zero 
for  the  estimated  value  and  for  which  the  true  value  is  1.  On  the  other  hand, 
very  reliable  algorithms  exist  for  numerical  integration,  see  [Lyness,  1Q791 
and  cited  works  for  more  details.  Great  practical  and  theoretical  advances 
have  been  made  in  symbolic  integration  since  the  1950s  [Moses,  197R1 ,  hut  there 
are  still  many  functions  which  cannot  be  integrated  so  numerical  integration 
must  be  used  often.  In  an  ideal  language,  symbolic  integration  would  be  used 
when  it  produces  results  quickly  and  numerical  integration  otherwise. 

4.  Infinite  Series  Summation.  An  infinite  series  is  of  the  basic  form 

00 

l  F(N) 

N=0 

where  F  is  a  function  defined  on  the  integers.  F  might  depend  on  variables 
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or  parameters  other  than  N.  Symbolic  methods  of  summation  exist,  but  aro 
probably  not  feasible  to  use. 

Rating:  Ease  =  65,  Importance  =  Jn 

Computational  experience  with  infinite  series  is  not  very  large,  but  it 
seems  plausible  that  the  difficulty  of  implementing  this  operator  reliably 
lies  somewhere  between  that  of  differentiation  and  integration. 

TOPIC  6:  Mathematical  Function  Definition  and  Manipulation 

A.  General  Discussion 

Functions  are  basic  items  in  mathematical  models  and  occur  pervasively  in 
numerical  computations.  It  is  essential  that  special  attention  be  paid  to 
providing  adequate  facilities  for  them. 

B.  Facilities 

1.  Natural  Definitions.  A  function  should  be  defined  in  a  natural, 
concise  form.  The  definition  should  be  an  independent  program  unit  with  all 
the  programming  language  facilities  available  for  the  definition.  It  is 
natural  to  have  functions  depend  on  both  "independent  variables"  and 
"parameters";  it  is  convenient,  but  not  essential,  that  this  distinction  be 
possible  in  the  function  definition. 

Rating:  Ease  =  90,  Importance  =  90 

Most  current  languages  provide  good  facilities  for  defining  functions. 

Hie  distinction  between  independent  variables  and  parameters  is  not  normally 
made  and  this  is  reflected  in  the  common  difficulty  in  using  something  like  a 
library  integration  routine.  The  routine  expects  as  argument  f(x)  and  the 
user  has  a  function  M(x,a,b,q)  where  a,  b  and  q  are  parameters.  Most 
current  languages  force  one  to  create  an  "intermediate"  function  from  M 
which  can  be  passed  to  the  integration  routine. 
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Functions  as  Program  Variables.  The  common  notation  of  scier.  -Is 


allows  one  to  manipulate  functions  as  separate  entities 

2 

[e.g.  h(x)  =  f(x)  +  A*(x  +  3  sin(x))}  and  a  programming  lanauaqe  car  .. ;  . 
this  also.  Different  choices  are  possible  for  the  treatment  of  parameters, 
that  is,  A  in  the  above  example  could  be  fixed  at  the  time  h(x)  is 
assigned  or  it  could  continue  to  be  an  ordinary  program  variable  (the  latter 
is  the  more  logical).  Functions  should  be  passed  between  programs  as  sinnle 
entities  in  a  natural  way. 

Rating:  Ease  =  30,  Importance  =  sc 

The  natural  manipulation  of  functions  appears  to  require  some  kind  of 
symbolic  facility  at  execution  time.  This  is  seen  as  a  large  burden  on 
languages  that  are  compiled;  some  slightly  limited  manipulation  facility  is 
probably  possible  through  manipulating  object  code  instead  of  source  code. 

This  facility  was  included  in  NAPSS  [1966). 

3.  Arrays  of  Functions.  Function  arrays  fi(x)  and  f^fx)  occur 
frequently  in  applications  (gradients,  Jacobians,  etc.).  In  principle, 
fi(x)  is  the  same  as  f(x,i)  but,  in  practice,  one  wants  to  allow  the 
vector/matrix  operations  of  the  language  to  apply  naturally  to  these  special 
kinds  of  functions.  The  rating  assumes  that  functions  are  already  include!  in 
the  language. 

Rating:  Ease  =80,  Importance  =  55 
Arrays  of  functions  were  included  in  NAPSS  [1966). 

4.  Mathematical  Typing.  Mathematics  has  a  large  number  of  schemes  to 
classify  (or  type)  functions  (e.g.  analytic,  polynomial,  differentiable, 
trigonometric) .  These  types  might  or  might  not  reflect  anything  about  the 
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r apresentati mns  ♦•‘•e  functions;  t"e  information  .  s 
functions  within  nat.hemat ical  procedures. 


Rating:  Ease  =  55 ,  Imnortan.ee  =  40 

It  is  anticipated  that  more  complete  languages  for  numerical  computation 
will  include  some  procedures  for  processing  functions  (e.g.  integration, 
differentiation).  The  algorithms  to  accomplish  this  must  either  "be  told"  or 
"discover"  various  properties  of  the  functions;  the  additional  information 
available  from  even  a  modest  typina  facility  can  increase  the  efficiency  of 
these  algorithms  dramatically.  If  the  symbolic  text  is  available  at  execution 
time  then  this  kind  of  information  could  be  obtained  by  a  symbolic  scan. 

TOPIC  7:  Inter-proaram  Communication 

A.  General  Discussion 

Inter-program  communication  is  a  "general"  programming  language  feature, 
but  certain  facilities  are  widely  needed  in  numerical  computations  which  are 
frequently  lacking.  The  facilities  are  usually  needed  by  large  programs  or 
libraries  and  the  need  is  probably  not  restricted  to  numerical  computation. 

B.  Facilities 

1.  global  Declaration.  A  declaration  like  GLOPAL  A,B,XYZ,...  should 
make  the  variables  named  available  to  all  programs  present  at  translation 
time . 


Rating:  Ease  =  BO,  Importance  =  ?n 

Many  large  numerical  software  projects  involve  a  model  of  something  which  is 
described  hy  program  variable.;.  These  variables  are  meaningful  to  everyone 
working  on  the  project  and  it  is  to  be  possible  to  agree  on  names  for  them  and 
then  allow  any  program  (of  the  project)  to  use  any  one  of  them  as  needed. 

2*  Partitioned  Global  Declarations.  Global  declarations  are  allowed  to 
have  different,  scopes.  Thus  GLOBAL  A,R>  GLOBAL  C,D  could  be  used  fo-  10 
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>-  V'  3  P  *  T  *  T  P1  ijro;^  fnr  3  c;p  .f  o  ^0  p  r*  o  rj  J*  C  .  rr,^*f' 

vjr  ia*-'.  »-•  r  ■->*  the  first  10  nr  oar  arts  would  not  conflict  with  the  variable 
::  f  *•'•>"■  secon  :  If. 

Pating :  Ease  =  70,  Importance  =  30 

This  facility  is  essentially  the  same  as  "Hiding  Names"  for  libraries.  It  is 
useful  for  "tor  down"  organizations  of  programs;  the  variables  of  programs  to 
handle  the  tail  assembly  of  an  airplane  need  not  be  aware  of  and  should  not 
conflict  with  variables  of  the  fuel  supply  systems. 

3.  Pubproaram  Argument  Lists.  The  argument  list  of  a  subproaram  can 
include  any  variable  of  a  program  in  a  simple,  direct  way. 

Rating :  Ease  =  55,  Importance  =  35 

The  essential  information  about  any  particular  program  variable  should  he 
attached  to  the  variable  and  passed  to  subprograms  (or  throuah  other 
communication  mechanisms!  along  with  the  variable.  Thus  a  matrix  is  passed 
along  with  its  dimension  and  range  information. 

4.  Internal  Procedures.  A  simple  procedure  (function)  to  he  defined 
inside  a  larger  program.  All  the  variables,  definitions,  etc.  of  the  larger 
program  extend  to  the  internal  procedure. 

Rating;  Ease  =  A5,  Importance  =  50 

This  is  a  simple  case  of  the  block  structure  of  Algol;  separate  compilation  of 
internal  procedures  would  not  occur.  It  is  very  natural  to  introduce  such 
procedures  and  sometimes  cumbersome  to  simulate  in  a  language  like  Fortran. 

5.  Variable  Argument  Lists,  Defaults.  The  number  of  arguments  to  a 
subprogram  should  allow  for  default  values  for  missing  values.  A  mechanism  to 
identify  arguments  explicitly  (instead  of  by  position  in  the  list)  is  needed. 

Rating:  Ease  =  40,  Importance  =  50 

A  common  problem  is  the  necessity  of  lengthy  argument  lists  where  most 
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revocations  use  only  a  part  of  the  variables  and  yet  valid  values  nust  he 
provided  for  the  unused  arguments.  A  scheme  like  FUNCTION  F(x,y,APAR  =  r, 

;  PAR  =  1.0,  LENGTH  =  ZAP)  would  allow  F(x,y)  to  be  used.  This  approach 
leads  to  complexity  if  only  LENGTH  is  to  be  provided,  e.g.  F(x,y,,,17).  An 
alternative  is  to  identify  arguments  (using  the  same  syntax  as  above)  so 
that  F(x,y)  is  equivalent  to  F( x ,y , 0, 1. 0, ZAP)  and  F(x,y, LENGTH  =  17.)  is 
equivalent  to  F( x ,y , 0, 1 . 0, 17. ) .  Note  that  this  particular  facility  could  be 
used  to  provide  a  distinction  between  independent  variables  and  parameters  for 
functions . 

TOPIC  8:  Standard  Mathematical  Functions 

A.  General  Discussion 

A  large  number  of  functions  have  been  identified  that  are  useful  in 
various  branches  of  mathematics,  statistics  and  science.  They  have 
standardized  definitions  and  are  part  of  the  "tools"  of  science  in  their 
particular  areas.  i 

B.  Facilities 

1.  Elementary  FMnctions.  These  functions  include  the  trigonometric 
(sine,  cosine,  secant,  arctan,  etc.),  exponential  and  logarithm, 
exponentiation  and  roots,  simply  evaluated  (absolute  value,  modulus,  etc.)  and 
the  hyperbolic. 

Rating:  Ease  =  95,  Importance  =  95 

These  functions  are  present  in  most  current  languages  and  there  is  a  large 
body  of  knowledge  about  their  efficient  evaluations  [Hart  et  al.,  1968], 

[Fike,  1968].  These  functions  permeate  scientific  computation. 

2.  Higher  Mathematical  Functions,  lhere  is  a  large  number  of  more 
specialized  functions,  often  called  higher  transcendental  functions,  which  are 


important  to  specific  fields  of  science.  The  more  common  ir.rl  ■:!.  7  ■  >: 

(factorial),  Bessel  functions.  Elliptic  Integrals  and  N'athieu  fur.rrif  ?, 

Rating :  Ease  =  9n  ,  Imp  r^arce 

The  inclusion  of  higher  mathematical  functions  does  not  pose  any  lanoua ce¬ 
des  iqn  problems;  there  is  an  increased  number  of  special  names  an  i  t hr  sv  • 
library  becomes  larger  as  more  of  these  are  included.  There  are  several 
general  references  for  these  functions  [Abramowitz  and  Ptegun,  1°64 ' , 

[Erdelyi,  195x-5y] .  Careful  analysis  of  evaluation  techniques  have  been  rale 
for  many  of  these  functions  [Cody,  197x]  ;  the  Collected  Algorithms  cf  the 
containing  many  instances.  Some  of  the  less  common  functions  have  never  bee: 
analyzed  for  computer  evaluation  and  are  evaluated  by  formulas  from  classical 
mathematical  analysis. 

TOPIC  9:  Exception  and  Error  Handling 

A.  General  Discussion 

A  common  situation  in  numerical  computation  is  the  use  of  multi-layered 
software  where  errors  may  occur  in  a  program  completely  unknown  to  the 
programmer,  the  operating  system  or  the  language  translator.  Thus  the 
language  itself  should  have  facilities  to  adequately  detect  errors  and 
exceptions  and  to  transmit  relevant  information  to  the  programmer.  The  four 
basic  types  of  errors  are:  (a)  Arithmetic  limits  exceeded  (overflow, 
underflow,  NAN  (Not-A-Number )  arithmetic) ,  (b)  Mathematical  Errors 
(1.10,  /-I.,  log(-2.3),  Ji/3 (“4.5) ) ,  (c)  System  Errors  (inadequate  storage, 
undefined  I/O  media,  time  exceeded)  and  (d)  Numerical  Failures  (Ax  =  b 

eft  2 

problem  with  A  singular,  sin(50  ),  solve  x  +  1  =  0). 

B.  Facilities 

1.  Identification  of  Error  Type.  A  complete  classification  of  errors  is 


defined  and  the  type  is  identified  in  the  error  report.  Relevant  parameters 


.-if  the  error  occurrence  are  provided  (e.u.  armr- -■  *"  :■  r  r  '  -rr-  -rs, 

data  for  svstem  routine  failures  (had  formats!'  . 

latino:  Care  =  -6 ,  Importance 

2.  Identification  of  Error  Location.  The  location  of  errors  should  he 
reported  in  the  prooranner '  s  terms  (i.e.  error  at  line  16  of  proaram  STTR1CX, 
called  from  line  14  of  nrST4 ) . 

Rating:  Ease  =  66,  Importance  =  PO 

The  language  implementation  is  to  maintain  a  record  at  execution  time  of 
r-  ;qran  locations  or  to  he  able  to  reconstruct  this  information  in  almost  all 
circumstances  (including  things  like  "time  exceeded",  "operator  abort"  or 
"illegal  input  format").  Absolute  address  tracing  through  system  loader 
mapping  tables  is  to  be  done  by  the  computer,  not  people. 

3.  Message  Transmission.  Messages  should  be  in  the  programmer's  terr¬ 
as  much  as  possible.  A  software  project  should  have  the  ability  to  modify  the 
messages  to  put  them  in  the  context  of  the  project. 

Rating :  Ease  =  7h,  Importance  =  7C 

4.  Error  Recovery  Control.  The  error  type  should  be  available  for  tes*- 
he^ore  an  irreversible  action  is  initiated.  The  language  should  allow  tests 
on  the  type  and  permit  the  program  to  remedy  or  modify  the  situation  without 
aborting  the  entire  computation. 

Rating:  Ease  =  75,  Importance  =  60 

Even  such  situations  as  "time  exceeded"  could  transfer  control  to  a  user 
program  for  a  final,  short  computation.  This  option  is  nice  for  small  or 
individual  projects,  it  is  almost  essential  for  robust,  user  oriented 
application  systems. 


-P.4- 


'•'a  viable  Tvpe  s 


/  .  >,r~oral  Discussion 

'■‘.a"  ti  's  has  developed  several  number  systems  that  occur  renularlv 
tamer ical  computation  and  there  are  number  systems  (e.g.  different  precisions' 
that  are  relevant  only  to  computation.  In  addition,  there  are  non-nuner ical 
tvnes  (e.ci.  strings)  that  many  programs  need  and  there  are  mathematical  data 
structures  (e.g.  vectors,  matrices,  function  arrays)  that  are  variable  types 
various  computationally  important  mathematical  systems. 

B.  Facilities 

1.  Real  Numbers.  Numerical  computation  cannot  occur  without  a 
reasonable  real  number  facility. 

Rating;  Ease  =  100,  Importance  =  100 

Most  meaningful  numerical  applications  require  a  precision  of  5  or  so  decimal 
digits  and  a  numerical  ranae  of  10±50  or  so.  Eight  to  ten  diqits  of 
precision  appears  to  be  an  economical  choice  for  the  basic  real  number 
arithmetic.  See  Reinsch  [1979]  for  a  detailed  analysis  of  the  properties 
reauired  of  real  number  arithmetic. 

?.  Integer  Numbers. 

Rating:  Ease  =  100,  Importance  =  15 

Inteqer  arithmetic  is  traditional  for  programming  languages,  but  there  is 
little  evidence  that  it  is  necessary  or  even  desirable  in  a  lanquage  for 
numerical  computation.  This  does  not  mean  that  certain  integer  oriented 
operations  (e.g.  fractional  part,  modulus)  can  be  omitted. 

3.  Higher  Precision  Real  Arithmetic.  Whatever  the  precision  of  the 
basic  real  arithmetic,  there  needs  to  he  an  additional  level  of  precision. 

Rating;  Ease  =  95,  importance  =  90 
The  basic  need  for  higher  precision  is  to  provide  a  mechanism  for  evaluating 


25- 


the  accuracy  of  numerical  computations.  This  need  is  recognized  in  the  desiur 
of  many  computers  where  hardware  is  present  for  double-precision.  People  who 
require  truly  extended  precision  (50,  500  or  5,000  decimal  diaits)  should  have 
access  to  a  portable,  unlimited  precision  package,  e.g.  Prent  MQ77). 

4.  Complex  Variables.  A  significant,  but  not  large,  proportion  of 
numerical  applications  require  the  complex  number  system. 

Rating;  Ease  =  70,  Importance  =  55 
Note  that  if  complex  arithmetic  is  included  then  two  levels  of  precision  are 
needed  to  provide  for  accuracy  testing. 

5.  Character  Strings.  The  basic  operations  (matching,  concatenation, 
etc.)  for  character  strings  are  needed  in  providing  user  oriented  output  and 
in  manipulating  data  of  various  types. 

Rating;  Ease  =  60,  Importance  =  50 

6.  Combinations.  Variable  types  tend  to  refer  to  different  attributes 
and  thus  be  natural  candidates  for  combining.  One  can  visualize  "Triple 
Precision  Complex  Positive  Definite  Band"  matrices  or  "Integer  *20  Complex 
Polynomial"  functions.  The  number  of  combinations  (and  effort  of 
implementation)  grows  rapidly  with  the  number  of  basic  types  to  be  combined. 

A  language  designer  can  attempt  some  general  "type  combination"  mechanism  or 
make  a  decision  on  which  combinations  are  worth  including. 

7.  Mathematical  Entities.  Variables  like  vectors,  functions  and 
matrices  are  considered  under  other  topic  headings  of  this  report. 


INCOMPLETE  DESCRIPTIONS 


TOPIC  1 1 :  Environment  Information 

1.  Numeric  Representations,  Word  Structure 

2.  Accuracy/Precision  Information 

3.  System  Information 
topic  12:  Precision  Control 

1.  General  Context,  Levels 

2.  Variable  Precision 

TOPIC  13:  Declarations,  Words  and  Names 
1 •  Declaration  Methods 

2.  Reserved  Words 

3.  Name  Structure 

TOPIC  14:  Problem  Solving  Statements 

1 .  Statement  Appearance 

2.  Flexibility 

TOPIC  15:  Storage  Management 

1.  Block  Storage  Allocation/Deallocation 

2.  Dynamic  Storage  Allocation 
TOPIC  16;  Data  Structures 

1.  Basic  Types  (Lists,  Stacks,  Queues,...) 

2.  Matrices 

3.  Trees 

4.  Graphs 
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